chore(auth): drop direct user-permission grants — roles only - #366

Closes #149. Final phase of the role-based permission epic (#142).

A permission reached a UserAccount three ways: a direct CongregationUserPermission row, a role on the account, or a role on its linked Member. This removes the first path, so the settings role screens become the single place access is granted — the epic's stated success criterion that no code path looks up a user's permissions directly.

Migration

20260826000000_drop_direct_user_permissions turns every direct grant into a role assignment, then drops the table. For each (congregation, permission) pair with at least one grant it creates one auto-role granting exactly that permission, keyed can-<verb>-<subject>.

Auto-roles are ordinary custom roles afterwards — isBuiltIn: false, renameable, deletable — with name and description left NULL. That is the convention built-in roles already use: getRoleDisplayName resolves the label from the message catalogue for the reader's locale, so no French or English text is pinned into the database, and an admin who renames one stores a name that then wins.

Collision guard. A congregation may already own a custom role slugified to can-do-anything — an admin is free to name a role "Peut tout faire". Adopting it would silently grant admin to everyone already assigned to it. A taken key falls back to <key>-migrated, then <key>-migrated-<permissionId>.

The test that matters

drop-direct-user-permissions.integration.test.ts captures every account's effective permission set before the backfill and asserts it is identical after — the "every user keeps the same effective permissions" criterion, and the only thing standing between this change and a silent authorization regression. The fixture covers:

• admin held only as a direct grant (the case the migration exists for)
• a user holding the same permission both directly and through a role (must not double-create, set must not change)
• a permission arriving through the linked Member's role (must be left completely alone)
• an account with nothing
• a second congregation that already owns can-do-anything granting something else

It reads the shipped SQL file rather than a paraphrase, so re-typing the migration cannot make it pass.

One deliberate compromise: the test executes the whole backfill but not the final DROP TABLE. Dropping takes ACCESS EXCLUSIVE not only on the table but on every table its foreign keys reference — UserAccount, Permission, Congregation — and the fixture holds that until rollback. Integration files run in parallel against one database, so executing it deadlocked unrelated suites at random. The drop is instead asserted as the migration's last statement; it is one self-evident statement, while the backfill is the part that can be wrong. Verified stable across three consecutive full integration runs.

Everything else

• resolveEffectivePermissions and accountsWithPermissionFilter walk roles only. The file's three-path header comment is now two.
• setupFirstAccount / registerCongregation hand the first account admin through ensureAdminRole, moved inside the scoped transaction — Role, RolePermission and UserRoleAssignment are RLS-scoped, unlike the unscoped direct grant they replace.
• updateAccount edits identity only. Its requireNotLastAdmin pre-check goes with the permission arm — that guard (and its stale "false positive" comment) is now redundant, since setUserCustomRoleAssignments already blocks removing an Admin-granting role from the last admin.
• Archive import keeps working. importCongregationUserPermissions still reads congregation-user-permissions.ndjson (and the pre-chore(auth): rename UserRole to Permission #152 congregation-user-roles.ndjson) and lands each grant on the matching auto-role, same collision rule as the migration — so restoring a pre-cutover backup doesn't silently drop everyone's access. Exports no longer emit the file; roles, role-permissions and role assignments travel as their own entities.
• The GDPR account export reports role-mediated permissions. anonymizeAccount drops the role assignments, which is what now revokes access.
• UI: the "Autorisations supplémentaires" card and the direct-permission count column are gone. edit-role.tsx prefills the name field from getRoleDisplayName so renaming an auto-role starts from its displayed name rather than an empty required field.
• Docs updated: permissions-and-roles.md (new Auto-roles section), architecture.md, notifications.md, data-transfer.md, row-level-security.md, CLAUDE.md.

Notes on the issue text

The issue predated some of the code and needed three corrections, all applied:

• It maps 16 permissions; there are 24. The 8 missing auto-role names were derived on the same can-<verb>-<subject> pattern and agreed before the migration was written.
• The direct-permission UI lives on /settings/users/:accountId/edit, not the publisher edit page (the UI refresh moved it). The user list also carried a "Permissions personnalisées" count fed by the same table.
• Archive import compatibility isn't mentioned in the issue but had to be handled.

Deployment

The control plane also reads this table, and was migrated off it first. Deployment order therefore matters; the coordination is tracked separately.

Testing

Written test-first throughout. pnpm test:unit (3154), test:integration (341), test:typecheck, test:lint, test:boundaries, test:aggregate-boundaries, test:tenant-scoping, test:server-barrel-exports, test:service-test-coverage, test:file-sizes and pnpm build all green.

Not done: a manual UI pass against a migrated local database.